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Softwire Provisioning Using DHCPv4 over DHCPv6 
Abstract 


DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically 
configuring IPv4 for use as an over-the-top service in an IPv6-only 
network.  Softwires are an example of such a service. For DHCPv4 
over DHCPv6 (DHCP 406) to function with some IPv4-over-IPv6 softwire 
mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the 
operator needs to know the IPv6 address that the client will use as 
the source of an IPv4-in-IPv6 softwire tunnel. This address, in 
conjunction with the client's IPv4 address, and (in some deployments) 
the Port Set ID are used to create a binding table entry in the 
operator's softwire tunnel concentrator. This memo defines a DHCPv6 
option to convey IPv6 parameters for establishing the softwire tunnel 
and a DHCPv4 option (to be used only with DHCP 406) to communicate 
the source tunnel IPv6 address between the DHCP 406 client and 
server. It is designed to work in conjunction with the IPv4 address 
allocation process. 


"DHCPv6 Options for Configuration of Softwire Address and Port-Mapped 
Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism 
for provisioning softwires. This document updates RFC 7598, allowing 
OPTION S46 BR (90) to be enumerated in the DHCPv6 client's Option 
Request Option (ORO) request and to appear directly within subsequent 
messages sent by the DHCPv6 server. 
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Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8539. 


Copyright Notice 


Copyright (c) 2019 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Deterministic IPv4-over-IPv6 transition technologies require that 


clients. 


the 


prefix, which is usually configured on the home gateway device. 


[RFC7598] 


deterministic softwires. 
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lements be preconfigured with binding rules for routing traffic to 
This places a constraint on the choice of address used as 
client's softwire source address: it must use a predetermined 


describes a DHCPv6-based mechanism for provisioning such 
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A dynamic provisioning model, such as using DHCPv4 over DHCPv6 (DHCP 
406) [RFC7341], allows much more flexibility in the location of the 
IPv4-over-IPv6 softwire source address. In this model, the IPv6 
address is dynamically communicated back to the service provider, 
allowing the corresponding softwire configuration to be created in 
the border relay (BR). 


The DHCP 406 client and softwire client could be run on end devices 
attached to a network segment using any routable IPv6 prefix 
allocated to an end user, located anywhere within an arbitrary home 
network topology. Dynamic allocation also helps to optimize IPv4 
resource usage, because only clients that are actively renewing their 
IPv4 lease hold on to the address. 


This document describes a mechanism for dynamically provisioning 
Softwires created using DHCP 406, including provisioning the client 
with the address of the softwire BR and informing the service 
provider of a client's binding between the dynamically allocated IPv4 
address and Port Set ID and the IPv6 address that the softwire 
initiator will use for accessing IPv4-over-IPv6 services. 


The mechanism operates alongside the DHCP 406 message flows to 
communicate the binding information over the IPv6-only network. The 
DHCP 406 server provides a single point in the network that holds the 
current client binding information. The service provider can then 
use this binding information to provision other functional elements, 
such as the BR(s). 


2. Applicability 


The mechanism described in this document is only suitable for use for 
provisioning softwire clients via DHCP 406. The options described 
here are only applicable within the DHCP 406 message-exchange 
process. Current softwire technologies suitable for extending to 
incorporate DHCP 406 with dynamic IPv4 address leasing include 
[RFC7597] and [RFC7596]. 


3. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 


"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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Solution Overview 


In order to provision a softwire, both IPv6 and IPv4 configurations 
need to be passed to the client. To map this to the DHCP 406 
configuration process, the IPv6 configuration is carried in DHCPv6 
options [RFC8415], carried inside the DHCPv6 message DHCPVA4-RESPONSE 
(21) sent by the server. OPTION S46 BR (90) is used to provision the 
remote IPv6 address for the softwire BR (see Section 4.1). 

OPTION S46 BIND IPV6 PREFIX (137) is optionally sent by the DHCP 406 
server to indicate to the client a preferred IPv6 prefix for binding 
the received IPv4 configuration and sourcing tunnel traffic. This 
may be necessary if there are multiple IPv6 prefixes in use in the 
customer network (e.g., Unique Local Addresses (ULAs)) or if the 
specific IPv4-over-IPv6 transition mechanism requires the use of a 
particular prefix for any reason. 


IPv4 configuration is carried in DHCPv4 messages [RFC2131] (inside 
the DHCP 406 option OPTION DHCPV4 MSG (87)) using the mechanism 
described in [RFC7341]. 


In order for the client to communicate the softwire source address, a 
new DHCPv4 option OPTION DHCP4O6 S46 SADDR (109) is defined in this 
document. This is included in DHCPREQUEST messages sent by the 
client and is stored by the server for the lifetime of the IPv4 
address lease. 


.1. Updating RFC 7598 to Permit the Reuse of OPTION S46 BR (90) 


Section 4.2 of [RFC7598] defines option OPTION 546 BR (90) for 
communicating remote softwire BR IPv6 address(es) to a client, but it 
mandates that the option can only be used when encapsulated within 
one of the softwire container options: OPTION S46 CONT MAPE (94) or 
OPTION S46 CONT LW (96). From Section 3 of [RFC7598]: 


Softwire46 DHCPv6 clients that receive provisioning options that 
are not encapsulated in container options MUST silently ignore 
these options. 


This document updates [RFC7598], removing this restriction for 
OPTION S46 BR (90), allowing it to be enumerated in the client's ORO 
request and appear directly within subsequent messages sent by the 
DHCPv6 server. 
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DHCP 406 IPv6/IPv4 Binding Message Flow 


Figure 1 shows the relevant extensions to the successful DHCP 406 
IPv4 allocation client/server message flow for the softwire source 
address function. The full process, including error handling, is 
described in Section 7. 


In each step, the DHCPv6 portion of the message and any relevant 
option is shown above the arrow. The DHCP 406 content of the message 
and its relevant options are below the arrow. All the DHCPv4 
messages are encapsulated in DHCPV4-QUERY (20) or DHCPVA4-RESPONSE 
(21) messages. Where relevant, the necessary options and their 
contents are shown. 


DHCP 406 DHCP 406 
Client Server 


DHCPv6 - DHCPV4-QUERY message containing 

OPTION ORO (6) listing (90, 137) 
SEGp:.l|[ee————-Re————————-———————————eeeeoeeceeocoeccuoeoe > 
DHCPv4 - DHCPDISCOVER message 


DHCPv6 - DHCPV4-RESPONSE message containing 
OPTION S46 BR(90), OPTION S46 BIND IPV6 PREFIX(137) 
(bind-ipv6-prefix with service provider's 
preferred prefix) 
Step 2 |«----------------------------------------------------- 
DHCPv4 - DHCPOFFER message 
containing an available IPv4 address 


DHCPv6 - DHCPVA4-QUERY message 
Step 3 |e9999—-58--9-9n-HBeeeHeReOEIHACHSOAnBOETUHLARAeHIEMSHHAedoTLe- > 
DHCPv4 - DHCPREQUEST message containing the 
requested IPv4 address and OPTION_DHCP406_S46_SADDR 
(softwire-ipv6-src-address with client's bound 
IPv6 softwire source address) 


DHCPv6 - DHCPV4-RESPONSE message 
Step.4:||[«osn———6Re6-————me.ec—cmELysPEEUIMMeEIUEM LC e 
DHCPv4 - DHCPACK message containing 
the leased IPv4 address and OPTION DHCPA4O6 S46 SADDR 
(softwire-ipv6-src-address with client's bound 

IPv6 softwire source address) 


Figure 1: IPv6/IPv4 Binding Message Flow 
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Step 1 The client constructs a DHCPv6 "DHCPV4-QUERY (20)" message. 
This message contains two options: DHCPv6 OPTION ORO (6) and 
OPTION DHCPVA MSG (87). OPTION ORO lists "90" 
(OPTION S46 BR) and "137" (OPTION S46 BIND IPV6 PREFIX). 
OPTION DHCPVA MSG contains a DHCPv4 DHCPDISCOVER message. 


Step 2 The server responds with a DHCPv6 "DHCPV4-RESPONSE (21)" 
message. This message contains an OPTION 546 BR (90) 
containing the IPv6 address of the BR for the client's 
softwire configuration. The message may also optionally 
contain OPTION S46 BIND IPV6 PREFIX (137). OPTION DHCPVA MSG 
contains a DHCPv4 DHCPOFFER message. The DHCPv4 message 
contains an available IPv4 address. 


Step 3 The client sends a DHCPv6 "DHCPV4-QUERY (20)" message 
containing a DHCPv4 DHCPREQUEST message with the requested 
IPv4 address and OPTION DHCPA4O6 S46 SADDR (109) with the IPv6 
address that the client will use as its softwire source 
address. 


Step 4 The server sends a DHCPv6 "DHCPVA-RESPONSE (21)" message. 
OPTION DHCPVA MSG contains a DHCPv4 DHCPACK message with the 
allocated IPv4 address. OPTION DHCPA4O6 S46 SADDR with the 
client's bound softwire source address is included. 


6. DHCP Options 
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option 


The format of the DHCPv6 source binding prefix hint option is as 
follows: 


0 1 2 3 
01234567890123456789012345678901 
*—R—-———L-—-—-— — LL. - 4-444444 
| OPTION S46 BIND IPV6 PREFIX | option-length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +t 
|bindprefix6-len| | 
+-+-+-+-+-+-+-+-+ bind-ipv6-prefix . 
i (variable length) 3 
ul 


Figure 2: Format of OPTION S46 BIND IPV6 PREFIX 


oO option-code: OPTION S46 BIND IPV6 PREFIX (137) 


o option-length: 1 + length of bind-ipv6-prefix, specified in bytes. 
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o bindprefix6-len: 8-bit field expressing the bit mask length of the 
IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 
128. 


o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix 
for the client to bind the received IPv4 configuration to. The 
length is (bindprefix6-len + 7) / 8. The field is padded on the 
right with zero bits up to the next octet boundary when 
bind-ipv6-prefix is not evenly divisible by 8. These padding bits 
are ignored by the receiver (see Section 7.4). 


OPTION S46 BIND IPV6 PREFIX is a singleton. Servers MUST NOT send 
more than one instance of the OPTION S46 BIND IPV6 PREFIX option. 


6.2. DHCP 406 Softwire Source Address Option 


The format of the DHCPv4 over DHCPv6 softwire source address option 
is as follows: 


0 1 
0.1.2 3 4 5 6 7 8 9 0 1 2 3 4 5 
R-—R--—4R--4R--4R--4R--4--4R--4R--4--4--4--4--4--4--4--4 


| option-code | option-length 

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- + 

+ softwire-ipv6-src-address + 
(128 bits) . 


€——— M— P 
Figure 3: Format of OPTION DHCPA4O6 S46 SADDR 
oO option-code: OPTION DHCP40O6 S46 SADDR (109) 
o option-length: 16. 
o Ssoftwire-ipv6-src-address: 16 bytes long; the IPv6 address that is 


associated (either being requested for binding or currently bound) 
with the client's IPv4 configuration. 


Note: The function of OPTION DHCPA4O6 S46 SADDR may seem similar to 
the DHCPv4 message's "chaddr" field or the Client Identifier (61) 
option in that it provides a unique lower-layer address that the 
Server can use for identifying the client. However, as both of these 
are required to remain constant throughout the address lease 
lifetime, they cannot be used with the mechanism described in this 
document. This is because the client may only be able to construct 
the IPv6 address to use as the source address after it has received 
the first DHCPVA4-RESPONSE message from the server containing 

OPTION S46 BIND IPV6 PREFIX. 
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7. Client Behavior 


A client requiring dynamic softwire configuration first enables DHCP 
406 configuration using the method described in Section 5 of 
[RFC7341]. If OPTION DHCPA O DHCP6 SERVER is received in the 
corresponding REPLY message, the client MAY continue with the 
configuration process described below. 


Before the dynamic softwire configuration process can commence, the 
client MUST be configured with a suitable IPv6 prefix to be used as 
the local softwire endpoint. This could be obtained using DHCPv6, 
Router Advertisement (RA) / Prefix Information Option (PIO), or 
another mechanism. 


7.1. Client Initialization 


When constructing the initial DHCP 406 DHCPDISCOVER message, the 
client includes a DHCPv6 OPTION ORO (6) within the options field of 
the DHCP-QUERY message. OPTION ORO contains the option codes for 
OPTION S46 BR (90) and OPTION S46 BIND IPV6 PREFIX (137). 


On receipt of the DHCP 406 server's reply (a DHCPVA4-RESPONSE 
containing a DHCPOFFER message), the client checks the contents of 
the DHCPv4-RESPONSE for the presence of a valid OPTION S46 BR option. 
If this option is not present, or does not contain at least one valid 
IPv6 address for a BR, then the client MUST discard the message, as 
without the address of the BR the client cannot configure the 
Softwire and so has no interface to request IPv4 configuration for. 


The DHCPV4-RESPONSE message may also include 

OPTION S46 BIND IPV6 PREFIX, which is used by the operator to 
indicate a preferred prefix that the client should bind IPv4 
configuration to. If received, the client first checks the option 
according to Section 7.4. If valid, the client uses this prefix as 
the "IPv6 binding prefix" and follows to the process described in 
Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to 
construct the softwire. If no match is found, or the client doesn't 
receive OPTION S46 BIND IPV6 PREFIX, the client MAY select any valid 
IPv6 prefix (of a suitable scope) to use as the tunnel source. 


Once the client has selected a suitable prefix, it MAY either use an 
existing IPv6 address that is already configured on an interface or 
create a new address specifically for use as the softwire source 
address (e.g., using an Interface Identifier constructed as per 
Section 6 of [RFC7597]). If a new address is being created, the 
client MUST complete configuration of the new address, performing 
duplicate address detection (if required) before proceeding. 
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The client then constructs a DHCPV4-QUERY message containing a DHCPv4 
DHCPREQUEST message. OPTION DHCP4O6 S46 SADDR is included in the 
options field of the DHCPREQUEST message with the IPv6 address of its 
softwire source address in the softwire-ipv6-src-address field. 


When the client receives a DHCPv4 DHCPACK message from the server, it 
checks the IPv6 address in OPTION DHCP4O6 S46 SADDR against its 
active softwire source address. If they match, the allocation 
process has concluded. If there is a discrepancy, then the process 
described in Section 7.5 is followed. 


If the client receives a DHCPv4 DHCPNAK message from the server, then 
the configuration process has been unsuccessful. The client then 
restarts the process from Step 1 of Figure 1. 


7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source 
Address 


Whenever the client attempts to extend the lease time of the IPv4 
address, OPTION DHCP4O6 S46 SADDR with the IPv6 address of its 
softwire source address in the softwire-ipv6-src-address field MUST 
be included in the DHCPREQUEST message. 


7.2.1. Changing the Bound IPv6 Softwire Source Address 
Across the lifetime of the leased IPv4 address, it is possible that 


the client's IPv6 address will change, e.g., if there is an IPv6 
renumbering event. 


In this situation, the client MUST inform the server of the new 
address. This is done by sending a DHCPREQUEST message containing 
OPTION DHCP406 S46 SADDR with the new IPv6 source address. 


When the client receives a DHCPv4 DHCPACK message from the server, it 
checks the IPv6 address in OPTION DHCPA4O6 S46 SADDR against its 
active softwire source address. If they match, the allocation 
process has concluded. If there is a discrepancy, then the process 
described in Section 7.5 is followed. 


If the client receives a DHCPv4 DHCPNAK message in response from the 
server, then the change of the bound IPv6 softwire source address has 
been unsuccessful. In this case, the client MUST stop using the new 
IPv6 source address. The client then restarts the process from Step 
1 of Figure 1. 
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7.3. Releasing the IPv4 Address Lease and Softwire Source Address 


When the client no longer requires the IPv4 resource, it sends a 
DHCPv4 DHCPRELEASE message to the server. As the options field is 
unused in this message type, OPTION DHCPA4O6 S46 SADDR is not 
included. 


7.4. OPTION S46 BIND IPV6 PREFIX Validation Behavior 


On receipt of the OPTION S46 BIND IPV6 PREFIX option, the client 
makes the following validation checks: 


o The received bindprefix6-len value is not larger than 128. 


o The number of bytes received in the bind-ipv6é-prefix field is 
consistent with the received bindprefix6-len value (calculated as 
described in Section 6.1). 


If either check fails, the receiver discards the invalid option and 
proceeds to attempt configuration as if the option had not been 
received. 


The receiver MUST only use bits from the bind-ipv6-prefix field up to 
the value specified in the bindprefix6-len when performing the 
longest prefix match. bind-ipv6-prefix bits beyond this value MUST be 
ignored. 


7.5. Client and Server Softwire Source Address Mismatch 


If the client receives a DHCPACK message with an 

OPTION DHCPA406 S46 SADDR containing an IPv6 address that differs from 
its active softwire source address, the client SHOULD wait for a 
randomized time interval and then resend the DHCPREQUEST message with 
the correct softwire source address. Section 4.1 of [RFC2131] 
describes the retransmission backoff interval process. 


The default minimum time for the client to attempt retransmission is 
60 seconds. If, after this time has expired, the client has not 
received a DHCPACK message with the correct bound IPv6 address, 
client MAY send a DHCPRELEASE message and restart the process 
described in Section 7. The retry interval should be configurable 
and aligned with any server policy defining the minimum time interval 
for client address updates as described in Section 8.1. 
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Use with Dynamic, Shared IPv4 Addresses 


[RFC7618] describes a mechanism for using DHCPv4 to distribute 
dynamic, shared IPv4 addresses to clients. The mechanism described 
in this document is compatible with IPv4 address sharing and can be 
enabled by following the process described in Section 6 of [RFC7618]. 


Server Behavior 


Beyond the normal DHCP 406 functionality defined in [RFC7341], the 
server MUST also store the IPv6 softwire source address of the client 
in the leasing address database, alongside the IPv4 address and 
client identifier. 


An OPTION DHCP4O6 S46 SADDR containing the bound softwire source 
address MUST be sent in every DHCPACK message sent by the server. 


The binding entry between the client's IPv6 softwire source address 
and the leased IPv4 address is valid as long as the IPv4 lease 
remains valid. 


Changing the Bound IPv6 Source Address 


In the event that the server receives a DHCPREQUEST message for an 
active IPv4 lease containing an OPTION DHCPA4O6 S46 SADDR with an IPv6 
address that differs from the address that is currently stored, the 
server updates the stored softwire source address with the new 
address supplied by the client and sends a DHCPACK message containing 
the updated softwire source address in OPTION DHCP4O6 S46 SADDR. 


The server MAY implement a policy enforcing a minimum time interval 
between a client updating its softwire source IPv6 address. If a 
client attempts to update the softwire source IPv6 address before the 
minimum time has expired, the server can either silently drop the 
client’s message or send back a DHCPACK message containing the 
existing IPv6 address binding in OPTION DHCPA4O6 S46 SADDR. If 
implemented, the default minimum client source address update 
interval is 60 seconds. 


Handling Conflicts between Clients' Bound IPv6 Source Addresses 


In order for traffic to be forwarded correctly, each customer edge's 
(CE's) softwire IPv6 source address must be unique. To ensure this, 
on receipt of every client DHCPREQUEST message containing 

OPTION DHCP4O6 S46 SADDR, the DHCP 406 server MUST check the received 
IPv6 address against all existing CE source addresses stored for 
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active client IPv4 leases. If there is a match for any active lease 
other than the lease belonging to the client sending the DHCPREQUEST, 
then the client's IPv6 source address MUST NOT be stored or updated. 


Depending on where the client and server are in the address leasing 
lifecycle, the DHCP 406 server then takes the following action: 


o If the DHCP 406 does not have a current, active IPv4 address lease 
for the client, then the DHCP address allocation process has not 
been successful. The server returns a DHCPNAK message to the 
client. 


o If the DHCP 406 does have a current, active IPv4 address lease, 
then the source address update process (s Section 8.1) has not 
been successful. The DHCP 406 server can either silently drop the 
client's message or return a DHCPACK message containing the 
existing IPv6 address binding in OPTION DHCP4O6 S46 SADDR. 


9. Security Considerations 


Security considerations that are applicable to [RFC7341] are also 
applicable here. 


A rogue client could attempt to use the mechanism described in 
Section 7.2.1 to redirect IPv4 traffic intended for another client to 
itself. This would be performed by sending a DHCPREQUEST message for 
another client's active IPv4 lease containing the attacker's softwire 
IPv6 address in OPTION DHCP4O6 S46 SADDR. 


For such an attack to be effective, the attacker would need to know 
both the client identifier and the active IPv4 address lease 


currently in use by another client. This could be attempted in three 
ways: 
1. One customer learning the active IPv4 address lease and client 


identifier of another customer via snooping the DHCP406 message 
flow between the client and server. The mechanism described in 
this document is intended for use in a typical ISP network 
topology with a dedicated Layer 2 access network per client, 
meaning that snooping of another client's traffic is not 
possible. If the access network is a shared medium, then 
provisioning softwire clients using dynamic DHCP406 as described 
here is NOT RECOMMENDED. 
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2. Learning the active IPv4 address lease and client identifier via 
snooping the DHCP406 message flow between the client and server 
in the aggregation or core ISP network. In this case, the 


attacker requires a level of access to the ISP's infrastructure 
that means they can already intercept or interfere with traffic 
flows to the client. 


3. An attacker attempting to brute-force guess the IPv4 lease 
address and client identifier tuple. The risk of this can be 
reduced by using a client identifier format that is not easily 
guessable, e.g., by using a random-based client identifier (s 
Section 3.5 of [RFC7844]). 


An attacker could attempt to redirect existing flows to a client 
unable to process the traffic. This type of attack can be prevented 
by implementing network ingress filtering [BCP38] in conjunction with 
the BR source address validation processes described in [RFC7596] 
Section 5.2 and [RFC7597] Section 8.1. 


A client may attempt to overload the server by sending multiple 
Source address update messages (see Section 7.2.1) in a short time 
frame. This risk can be reduced by implementing a server policy 
enforcing a minimum time interval between client address changes, as 
described in Section 8.1. 


9.1. Client Privacy Considerations 


[RFC7844] describes anonymity profiles for DHCP clients. These 
considerations and recommendations are also applicable to clients 
implementing the mechanism described in this document. As DHCP 406 
only uses DHCPv6 as a stateless transport for DHCPv4 messages, the 
"Anonymity Profile for DHCPv4" described in Section 3 is most 
relevant here. 


In addition to the considerations given in [RFC7844], the mechanism 
that the client uses for constructing the interface identifier for 
its IPv6 softwire source address (s Section 7.1) could result in 


the device being trackable across different networks and sessions, 
e.g., if the client's softwire Interface Identifier (IID) is 
immutable. 


This can be mitigated by constructing the softwire source IPv6 
address as per Section 6 of [RFC7597]. Here, the address's IID 
contains only the allocated IPv4 address (and port set identifier if 
[RFC7618] is being used). This means no additional client 
information is exposed to the DHCP 406 server; it also means that the 
IID will change as the leased IPv4 address changes (e.g., between 
sessions when Section 3.5 of [RFC7844] is implemented). 
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IANA Considerations 


IANA has assigned the OPTION S46 BIND IPV6 PREFIX (137) 
from the DHCPv6 "Option Codes" registry maintained at 
«http://www.iana.org/assignments/dhcpv6-parameters» as follows: 


option code 


Value: 137 

Description: OPTION_S46_BIND_IPV6_PREFIX 
Client ORO: Yes 

Singleton Option: Yes 

Reference: RFC 8539 


IANA has assigned the OPTION_DHCP406_S46_SADDR (109) option code from 
the "BOOTP Vendor Extensions and DHCP Options" registry maintained at 
«http://www.iana.org/assignments/bootp-dhcp-parameters» as follows: 


IANA has updated the entry for DHCPv6 OPTION S46 BR 


"Option Codes" registry maintained at 


Tag: 109 

Name: OPTION DHCPA4O6 S46 SADDR 

Data Length: 16 

Meaning: DHCPv4 over DHCPv6 Softwire Source Address Option 
Reference: RFC 8539 


(90) in the 


<https://www.iana.org/assignments/dhcpv6-parameters> as follows: 


Old 


New 


Entry: 


Value: 
Description: 
Client ORO: 


Singleton Option: 


Reference: 
Entry: 
Value: 


Description: 
Client ORO: 


Singleton Option: 


Reference: 


et al. 


90 
OPTION S46 BR 
No 

No 

[RFC7598] 


90 
OPTION S46 BR 
Yes 
No 


[RFC7598], [RFC8539] 
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